[% setvar title The Perl 6 Summary for the week ending 20030323 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20030323'></a><h1>The Perl 6 Summary for the week ending 20030323</h1>
<p>Assuming I can tear myself away from stroking the cat who has just
magically appeared on my chest and is even now trying to wipe his dags
on my nose, welcome one and all to another Perl 6 summary, which
should go a lot quicker now that Sully has moved off and let me see
the screen. He'll be back though. But before that happens we'll start
with perl6-internals.</p>
<a name='Speed question: save/restore vs push/pop'></a><h2>Speed question: save/restore vs push/pop</h2>
<p>Benjamin Goldberg wondered about how many <code>save</code>s it takes to be
slower than one <code>pushx</code>. Steve Fink pointed out that <code>save</code> and
<code>pushx</code> are not interchangeable as they push things onto totally
different stacks (<code>save</code> pushes onto the generic user stack, <code>pushx</code>
push onto type specific register frame stacks). Leo T&ouml;tsch
ignored this difference (which Ben was apparently aware of) and did
some tests which showed that, on his local architecture and core, 2
saves were slower than one push. On Dan's machine, it took 3 saves to
be slower than one push. Dan also pointed out that, on some
architectures, there's a subtle win with saves because a push would
dirty the L1 and L2 caches while the save wouldn't. (On SPARC at
least, apparently).</p>
<p><a href='http://groups.google.com/groups?threadm=3E756D30.1A1E32CD@earthlink.net' target='_blank'>groups.google.com</a></p>
<a name='Baby Steps in porting IO to the PIO architecture'></a><h2>Baby Steps in porting IO to the PIO architecture</h2>
<p>Last week, Leon Brocard posted his implementation of the <b>uniq(1)</b>
Unix utility to PASM. This week, J&uuml;rgen B&ouml;mmels' ongoing
project of moving Parrot's IO operators from the STDIO library to
Parrot's own PIO library (which is asynchronous and a combination of
lovely and scary by all reports.) broke this because PIO didn't have
any read buffering capabilities, which means that the <code>readline</code> op
didn't work.</p>
<p>On Monday, J&uuml;rgen had write buffering working, which Dan applied
with alacrity while making noises about needing to finish up the
documentation for Parrot's asynchronous IO system. There was some
debate on whether a PIO flush should force a write to the disk, or
simply ensure that all the buffers were flushed to the OS. Nicholas
Clark discussed some issues he'd had with Perl 5.8's PerlIO system,
and the need for two different kinds of flush, or more succinctly, the
need to distinguish 'flush' from 'sync'. Dan was convinced by this
argument and Steve Fink seconded the decision.</p>
<p>Then, on Sunday, J&uuml;rgen released a patch which got read
buffering working. Dan had a few problems with it and the patch hadn't
been applied by the end of the week. I'm sure it'll go in like a
greased weasel once that's been fixed though.</p>
<p><a href='http://groups.google.com/groups?threadm=rt-21600-53762.1.82033716216168@bugs6.perl.org' target='_blank'>groups.google.com</a> -- J&uuml;rgen adds
write buffering</p>
<p><a href='http://groups.google.com/groups?threadm=20030318215758.GD290@Bagpuss.unfortu.net' target='_blank'>groups.google.com</a> -- Nicholas discusses
different types of <code>flush</code></p>
<p><a href='http://groups.google.com/groups?threadm=rt-21656-53999.2.32338126263997@bugs6.perl.org' target='_blank'>groups.google.com</a> -- J&uuml;rgen adds
read buffering</p>
<a name='PBC Object Files'></a><h2>PBC Object Files</h2>
<p>Michael Collins wondered if it might be a good idea to come up with a
parrot 'object file' specification. I liked Michael's description of
an object file as 'a file that contains compiled instructions plus a
section with a table that maps subroutine/constant labels to their
corresponding byte offsets within the file.' Leo T&ouml;tsch's answer
was 'not yet'. Apparently the basic functionality is there but there
are some cleanups and a couple of opcodes needed.</p>
<p><a href='http://groups.google.com/groups?threadm=3e7647b7.c774.0@bestweb.net' target='_blank'>groups.google.com</a></p>
<a name='Parrot binaries'></a><h2>Parrot binaries</h2>
<p>Ask Bj&oslash;rn Hansen posted to say that he'd been trying to make
an RPM <b><i>.spec</i></b> file for parrot and had noted the lack of a <code>make
install</code> target. He also wondered about the permissions of various
files in the distribution, which seem somewhat cockeyed. Steve Fink
posted a patch which covered some of this (or at least the make
install and RPM issues) with tools which would generate RPMs and asked
for comments on his work. Leo T&ouml;tsch liked it and offered a
couple of suggestions</p>
<p><a href='http://groups.google.com/groups?threadm=86u1e0x1sf.fsf@miette.develooper.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20030319175639.GF662@foxglove' target='_blank'>groups.google.com</a> -- Steve's working patch</p>
<a name='Some comments on PDD 14 Big Numbers'></a><h2>Some comments on PDD 14 Big Numbers</h2>
<p>Mark Biggar, who implemented the original Big* packages for Perl had
some suggestions about Parrot's big number handling based on PDD
14. Benjamin Goldberg wondered if it would be a good idea to design
our BigInt type so that we could replace the maths engine with a
different engine so that users could pick which ever engine they
prefer as configuration option, and so that new maths engines could be
added without having to make wholesale changes.</p>
<p><a href='http://groups.google.com/groups?threadm=3E77BD4F.5090006@attbi.com' target='_blank'>groups.google.com</a></p>
<a name='99 bottles of beer on the wall'></a><h2>99 bottles of beer on the wall</h2>
<p>Douglas Hunter appears to have noticed that, up until now, Parrot had
lacked a vital program -- one which would output the lyrics to that
well known song, <i>99 Bottles of Beer on the Wall</i>. So, being a
community spirited kind of chap, he implemented just that and posted
it to the list. A few people quibbled about his style (unnecessary
labels, that sort of thing). Leo T&ouml;tsch pointed out, with the
aid of some IMCC output that the optimizer caught those issues anyway,
and added the code to the Parrot distribution's <b><i>examples/</i></b>
directory. Well done Douglas, it's good to see Parrot being used for
essential applications like this. I'm just surprised nobody has yet
benchmarked the Parrot implementation against Perl and Python. This
may just be the test application we need for the Parrot/Python speed
challenge.</p>
<p><a href='http://groups.google.com/groups?threadm=3E78F149.3020502@plusthree.com' target='_blank'>groups.google.com</a></p>
<a name='BASIC, IMCC and Windows'></a><h2>BASIC, IMCC and Windows</h2>
<p>Clinton A Pierce has been having a hard time making good on his offer
to produce a milestone Windows binary for distribution. He's having a
hard time building IMCC because it seems to want headers that MSVC++
isn't happy with. Dan  noted that this needs to be fixed before the
next release of Parrot (which will be either 0.1.0 or
0.0.11) because he wants to get rid of the IMCC/parrot difference and
just have a single binary. Leo T&ouml;tsch and Nicholas Clark offered
a few suggestions about workarounds, but it looks like there's still
no Windows distribution for Parrot.</p>
<p><a href='http://groups.google.com/groups?threadm=3E7AF5A0.7010104@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Iterator Proof of Concept'></a><h2>Iterator Proof of Concept</h2>
<p>Following the deafening response to his Iterator proposal of last
week, Leo T&ouml;tsch agreed with me that that must mean that
everyone liked the idea and posted a proof of concept patch and
invited comments. Nobody has yet done so.</p>
<p><a href='http://groups.google.com/groups?threadm=3E7C4808.8090801@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='vtable_1 - accessor macros'></a><h2>vtable_1 - accessor macros</h2>
<p>Leo T&ouml;tsch has started work on hiding vtable functions and
posted his first patch. He commented that the new accessor macros seem
to make for more readable source files. He asked if people were okay
with the macro, as the next step would be to start using the macros
all over the parrot source. Nicholas Clark liked the basic idea, but
worried about documentation, and about the possibility of scary macro
layering a la Perl 5. He also wondered if it would be possible to
conditionally write them as inline functions, which would make
debugging easier. Leo didn't see much point in making this particular
set of macros into inline functions as they were simple translations
with no complex functionality.</p>
<p><a href='http://groups.google.com/groups?threadm=3E7D886A.8050502@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Parrot 0.0.10 released'></a><h2>Parrot 0.0.10 released</h2>
<p>Parrot version 0.0.10, codename 'Juice' was released on
Wednesday. Steve Fink rounded up the usual list of improvements and
generally did a good job of letting the world know about the new
Parrot release. If you want the details, follow the link.</p>
<p><a href='http://groups.google.com/groups?threadm=20030319033557.GD23200@foxglove' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, over in perl6-language'></a><h1>Meanwhile, over in perl6-language</h1>
<p>perl6-language was again the busier list this week. The fallout from
Apocalypse 6 continues both with clarifications of what was in that
document and some suggestions inspired by it.</p>
<a name='is static?'></a><h2>is static?</h2>
<p>Towards the end of last week, Uri Guttman had asked about a possible
'is static' variable trait, and the discussion carried on into the
this week. Arcadi Shehter suggested using <code>has</code> to introduce a static
variable:</p>
<pre>    sub foo () {
        has $s //= 0;
        $s ++;
    }</pre>
<p>Larry described this as a <i>very</i> interesting idea, but was concerned
that this might be akin to overloading the meaning of <code>has</code> in the
same way that C overloaded the meaning of <code>static</code>. Damian also
worried that using 'has' in this way would mean stretching 'the concept
of objects a little too far'. He also thought that using <code>//=</code> to
initialize such a variable felt wrong, and that maybe we needed a
third assignment operator to go with 'assign unless true (<code>||=</code>)' and
'assign unless defined (<code>//=</code>)', which could be thought of as 'assign
unless exists' and suggested <code>??=</code> as a possible (though he didn't
profess to actually like it). Damian also thought that such
functionality should really be introduced with a trait and suggested a
list of possible trait names. Uri was unconvinced by any of Damian's
alternatives and proposed deciding the name with a duel on the beach
at Boca Raton.</p>
<p>Larry decided that using a trait to denote a 'static' variable would
be the wrong way to go because such a variable has a different kind of
scope from a <code>my</code> variable and described the whatever declaration was
eventually settled on as introducing a lexically scoped alias to a
property of the current block. Larry later suggested <code>state $s = 0</code>
because 'a static var makes a subroutine stateful'. Uri wasn't sure,
but Damian liked it.</p>
<p>Arcadi Shehter wondered about scoping of lexically scoped subs and if
they could really be thought of as lexically scoped at all, whereupon
he and Mattijs van Duin got a bit tangled up with the various kinds of
scoping available, but there's been no definitive comment from Damian
or Larry about the correct behaviour.</p>
<p><a href='http://groups.google.com/groups?threadm=15988.34979.963066.105078@gargle.gargle.HOWL' target='_blank'>groups.google.com</a></p>
<a name='On the place of Scalar in any class hierarchy'></a><h2>On the place of Scalar in any class hierarchy</h2>
<p>During the discussion last week about strictness and type coercion on
function calls, some confusion arose about whether <code>Int isa Scalar</code>,
or <code>Scalar isa Int|String|Float|...</code>. David Whipp proved himself a
hero by posting on this subject, pointing out that Scalar is the type
of the variable, not of the value (I'd probably replace variable with
'container', but I'm picky like that) and explained how this solved
some of the problems people had been having. There was no comment from
Larry or Damian about this post, but I thought it was wonderful.</p>
<p><a href='http://groups.google.com/groups?threadm=20030317191207.1000.qmail@onion.perl.org' target='_blank'>groups.google.com</a></p>
<a name='A6 questions'></a><h2>A6 questions</h2>
<p>Dave Storrs posted a grab bag of questions about Apocalypse 6 and got
a grab bag of answers.</p>
<p><a href='http://groups.google.com/groups?threadm=20030316140934.C14569@megazone.bigpanda.com' target='_blank'>groups.google.com</a></p>
<a name='Apoc 5 - some issues'></a><h2>Apoc 5 - some issues</h2>
<p>Matthijs van Duin had a pile of questions and issues with Apocalypse
5. Some of the questions were Hard. Only Luke Palmer dared answer
them. He and Matthijs batted things back and forth a few times, but it
looks like Matthijs still had some issues with backtracking into and
over closures.</p>
<p><a href='http://groups.google.com/groups?threadm=20030317143550.GK547@cds.nl' target='_blank'>groups.google.com</a></p>
<a name='&quot;XML is Too Hard for Programmers&quot;'></a><h2>&quot;XML is Too Hard for Programmers&quot;</h2>
<p>Rich Morin pointed everyone at Tim Bray's article about XML being hard
to deal with in most programming languages. Robin Berjon chipped in
with a pointer to an xml-dev thread on the same subject. There was a
certain amount of muttering about companies that use formats that seem
to walk like XML but fail to quack like XML (the initials M &amp; S were
used, and I don't think they were referring to Marks and
Spencer). Michael Lazzaro made an impassioned plea for insuring that
Perl 6 allows easy, fast parsing of XML-like things out of the
box. Austin Hastings suggested that Michael should take command of
P6ML. Dan pointed to a basic Parrot XML parser in the Parrot examples
directory that was at least four times faster than the equivalent Perl
5 code that it's a line for line translation of, and noted that the
performance numbers were old.</p>
<p><a href='http://groups.google.com/groups?threadm=p05200f03ba9d00b87d1d@' target='_blank'>groups.google.com</a>[192.168.254.205]</p>
<p><a href='http://www.tbray.org/ongoing/When/200x/2003/03/16/XML-Prog' target='_blank'>www.tbray.org</a> -- Tim
Bray's article</p>
<p><a href='http://lists.xml.org/archives/xml-dev/200303/msg00536.html' target='_blank'>lists.xml.org</a> --
xml-dev thread</p>
<a name='Rules and hypotheticals: continuations versus callbacks'></a><h2>Rules and hypotheticals: continuations versus callbacks</h2>
<p>Remember what I said about Matthijs van Duin still having some issues
with backtracking? Well, he kicked off a whole new thread just to
discuss it and two possible methods for implementing the grammar
system (labelled the 'backtracking continuation' and 'callback'
methods). Mattijs would like to see the backtracking continuation
method blessed as the right way. (He discusses all this here because
the choice of implementation could well have language level
implications). Luke Palmer was concerned that both of Mattijs's
proposed implementations would be very slow and had a couple of other
possible implementation approaches (the 'success continuation' and
'backtrack exception' methods). Mattijs reckoned that the success
continuation approach was pretty much the same as his 'callback'
method, and that the 'backtrack exception' method seemed to have
problems with rules like <code>&lt;foo&gt; &lt;bar&gt;</code>. And then it all got very
complicated as Dan and Matthijs went back and forth at the issue with
occasional interjections from others where appropriate. Then someone
mentioned threads...</p>
<p>Dan and Matthijs seem to have very different sets of assumptions which
leads one to suspect that they're arguing past each other on
occasion. I certainly found myself wishing there was somewhere
convenient with an ample supply of chalkboards, chalk, index cards and
Sharpies and other high bandwidth communication aids where they could
go and come to some kind of understanding.</p>
<p>At one point Austin Hastings observed that 'when anyone says &quot;I don't
see why anyone would ...&quot;, Damian immediately posts an example of
why. Unless it's Damian, in which case Simon, Larry, or Dan usually
counterpost.' Hey, it made me smile.</p>
<p>I think Larry's only contribution to this thread bears repeating in
its entirety:</p>
<p>I would like to express my sincere gratitude to all of you for working
through these issues.  I bent my brain on the Perl 5 regex engine, and
that was just a &quot;simple&quot; recurse-on-success engine--and I'm not the
only person it drove mad.  I deeply appreciate that Perl 6's regex
engine may drive you even madder.  But such sacrifices are at the
heart of why people love Perl.  Thanks!</p>
<p><a href='http://groups.google.com/groups?threadm=20030318195515.GA8498@cds.nl' target='_blank'>groups.google.com</a></p>
<a name='Questions to Help Program Perl6::Parameters'></a><h2>Questions to Help Program Perl6::Parameters</h2>
<p>Brent Dax is working on a Perl6::Parameters source filter for Perl 5,
a task he describes as 'damn hard'. He had a couple of questions about
argument behaviour. Damian had the answers, and made noises about his
forthcoming module, Perl6::Rules. Simon muttered something about
Parse::FastDescent (but everyone passed over that) and pointed out
Matthijs van Duin's work in progress.</p>
<p>Larry thanked Brent for taking on the task and 'suffering vicarious
pain for the user' and mentioned that he was interested in feedback on
spots where the design impacts performance unduly. Larry went on to
discuss possible changes to the scoping of <code>$_</code> to help with with the
transition from Perl 5 to Perl 6. He and Damian proceeded to discuss
other entertaining syntax possibilities to do with <code>want</code>, <code>where</code>
and <code>when</code>. Nobody has yet proposed meaningful semantics for <code>what</code>,
<code>who</code> and <code>why</code>, but I'm sure somebody will get 'round to it.</p>
<p><a href='http://groups.google.com/groups?threadm=013901c2ed93$58d64cd0$6501a8c0@deepblue' target='_blank'>groups.google.com</a></p>
<p><a href='http://www.liacs.nl/~mavduin/P6P5_0.00_01.tar.gz' target='_blank'>www.liacs.nl</a> -- Matthijs' work
in progress</p>
<a name='.req or .arity?'></a><h2><code>.req</code> or <code>.arity</code>?</h2>
<p>Austin Hastings asked that Routine's <code>.req</code> method be renamed
<code>.arity</code>. Damian rather liked the idea. Larry wasn't so sure because
<code>.arity</code> is somewhat opaque to non-mathematicians, but he accepted
that one could argue that anyone who doesn't know what arity means
shouldn't be writing code that depends on it. Steffen M&uuml;ller
thought that either <code>.req</code> or <code>.reqargs</code> would be a better name for
the method.</p>
<p>For those who don't know, 'arity' is the number of arguments a
function or operator takes.</p>
<p><a href='http://groups.google.com/groups?threadm=20030318230916.30389.qmail@web12306.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<a name='Acknowledgements, Announcements and Apologies'></a><h1>Acknowledgements, Announcements and Apologies</h1>
<p>And another summary rolls towards its close. I'd like to echo Larry's
thanks to everyone who's working on scary magic like the Perl 6 rules
engine and Perl6::Prototypes. The way people like Brent, Matthijs,
Leo and Luke have stepped up to the plate for this undeniably Hard
Stuff is, frankly, inspirational. It's people like you who keeps me
bullish about Perl 6.</p>
<p>Thanks too to everyone else involved in either list; Michael Lazzaro
made the point that often the most productive way for perl6-language
to proceed is for an initial suggestion to be thrown out onto the
list, then everyone has a good long wibble about it going off in about
3000 different directions at once before someone (usually one of
Damian, Larry or Allison but not necessarily) pulls it all together
into something that makes sense and we move on to the next item. My
gut tells me that without all the wibbling the end result wouldn't be
quite so satisfying.</p>
<p>For instance, much as I hated trying to summarize the everlasting
pipeline thread, the end results of that discussion are the rather
lovely <code>==&gt;</code> and <code>&lt;==</code> operators that appeared in the latest
Apocalypse. (Of course, Larry or Damian will probably respond to this
summary by telling me that actually, they'd been planning something
like that all along. I just won't necessarily believe them)</p>
<p>If you appreciated this summary, please consider one or more of the
following options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ and help support the ongoing development of Perl.'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and help support the ongoing
development of Perl.</li>
<li><a name='Get involved in the Perl 6 process. The mailing lists are open to all. dev.perl.org/perl6/ and www.parrotcode.org/ are good starting points with links to the appropriate mailing lists.'></a>Get involved in the Perl 6 process. The mailing lists are open  to
all. <a href='http://dev.perl.org/perl6/' target='_blank'>dev.perl.org</a> and <a href='http://www.parrotcode.org/' target='_blank'>www.parrotcode.org</a>
are good starting points with links to the appropriate mailing lists.</li>
<li><a name='Send feedback, flames, money, photographic and writing commissions, or a print of Mark Citret's Empty Room to p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a>'></a>Send feedback, flames, money, photographic and writing commissions, or
a print of Mark Citret's <i>Empty Room</i> to <i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i></li>
</ul>
<p>This week's summary was again sponsored by Darren Duncan. Thanks
Darren. If you'd like to become a summary sponsor, drop me a line at
<i><a href='http://search.cpan.org/perldoc?<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>'>p<a href='mailto:6summarizer@bofh.org.uk'>6summarizer@bofh.org.uk</a></a></i>.</p>
</div>
